Subject: Re: Elimination of LLC Connection in HPR

From: "jim (j.) cobban" <[email-masked]>
Date: Wed, 2 Aug 1995 10:37:00 -0400

In message "Re: Elimination of LLC Connection in HPR", Dave Finnie
<[email-masked]> writes:

> * There needs to be a "new" method to know when a link is up. Since
>   no mode setting command is used, and CS logic requires one
>   currently, we need some method to identify when the XID exchange is
>   complete.

CS logic does not require that a mode setting command be transmitted on the
medium, merely that one be exchanged with the DLC process.  As far as CS is
concerned the link is up as soon as the XID exchange is complete.  In
particular look at case 5 in figure 9-31 on page 9-106 of the AR.  PC is
created, and ASM is notified, as soon as the XID exchange is complete.  Only
once ASM responds is a SET_MODE signal sent to DLC (figure 9-32 on page
9-108).  Note that CS always sends a SET_MODE signal to DLC even if this end
of the link has negotiated to secondary, and therefore the SET_MODE signal
will not trigger the immediate transmission of a "frame" on the link.  Even
if no mode-setting command is sent on the medium the SET_MODE signal is still
required to go from CS to DLC because, among other things, it is the signal
which carries the process ID of PC.

> * LLC2 does provide reliable delivery of XIDs for CS (although
>   duplicates may occur if timer values are chosen
>   inappropriately). This will no longer be the case. This, of course,
>   applies to activation as well as non-activation flows.

This statement is true of the "LLC2" definition in the IBM Token-Ring
Architecture Reference.  It is NOT true of the LLC2 definition in ISO 8802.2.
That means that it definitely does not apply to any medium other than
Token-Ring implementations which comply to the IBM definition, as opposed to
the ISO 8802.5 definition.  We have also observed that reliable delivery of
XIDs is also not true of all TRN adapter microcode implementations.  In
particular the TI microcode does NOT retransmit XIDs.  Reliable delivery of
XIDs is therefore, in many implementations, a responsibility of the DLC code,
rather than of "LLC2".  There is therefore no implementation dependency
between the use of ABM for the exchange of I frames reliably, and the SNA
requirement for reliable delivery of XIDs.

> * Without having investigated it at all, I think some action may need
>   to be taken to detect link outage. For links between nodes that
>   have CP-CP sessions, the timeout of the CP-CP session could be used
>   to determine if the link had timed out. However, CP-CP sessions may
>   not be present (either through function (eg EN-EN), or
>   configuration). So some non-CP-CP session based method of detecting
>   link outage would be required.

You have an excellent point there.  Although RTP will detect the loss of
connectivity, when it tries to do a path switch TRS will give it the same
path, because TRS has not been notified of the failure.  However is
exchanging RR frames all day long, and tieing up 1/255th of a limited
resource on the adapter a good reason to use this technique?

---

From: [email-masked] (Dave Finnie)
Date: Thu, 3 Aug 1995 12:21:07 +1000

Jim,

> which carries the process ID of PC.

Yes, I see your point. I wonder, though, why TR LLC2 has architected a reliable
delivery of SABME, with the UA, and then RR as a 3-way handshake to make sure
the link is up. Perhaps they were covering some strange conditions that we
should also be wary of ? Does anyone know why this is done ?

> requirement for reliable delivery of XIDs.

Well, the definitely is not correct, since we implement TR LLC2 spec for Ethernet,
FDDI and TR, and have had not problems in this area. Surely the following need to
apply:

  * Since these LAN protocols can easily be bridged, the method should theoretically
    be the same for all of them

  * CS *does* in fact expect the XID to be delivered when it tells DLC to.

I'm a little confused by your use of DLC. DLC in this context actually consists
of 2 sublayers - LLC, and MAC. Since you are saying that XID Retry is not the
role of the LLC, does that mean you believe it is the role of the MAC ? I do
not agree with this. The MAC should only attempt to retransmit frames that it
had problems with at the MAC level (eg collision, in Ethernet). Since a bridge
or something else could discard an XID even if it was successfully retransmitted,
it makes sense to me that XID should be retried by LLC2. Clearly LLC1 is a 
connectionless (and unacknowledged) service, and therefore should not retry
anything. So it seems that rather than move the functionality down, we need to
move retransmit back up to CS for LLC1-only HPR links.

Dave

---

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 8 Aug 1995 08:45:00 -0400

In message "Re: Elimination of LLC connection in HPR", Dave Finnie writes:

>I like the idea of using a separate (or particular) NCE for the keep
>alive traffic. Because NCEs are administered locally, this NCE value
>would need to be transmitted via XID - and potentially a different NCE
>value could be used in each direction on a link, but that is not a big
>issue.

I agree that a separate NCE should be used for a keep-alive flow.  Since the
LLC2 connection can only be suppressed if the Control Flows over RTP Tower is
supported, and since the CFoRT subfield of the CV 61 already contains two
NCEs (the CP NCE and the Route Setup NCE), it would seem symmetrical to add
the Keep-Alive NCE into this subfield.  I don't see any backwards
compatibility problem.  The only nodes which would recognize this NCE would
be ones which were also sending it, and unless such a node received a
keep-alive NCE in the SF 81, it would activate the LLC2 connection normally.

Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars153!jcobban       |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Bell-Northern Research or Northern Telecom.     |